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(54) Verfahren, System und Gateway, die einen End-zu-End gesicherten Zugriff auf WAP-Dienste 
erlauben 



(57) Verfahren, mil welchem ein Mobilteilnehmer 
mit einem WAP-tauglichen Endgerat (1) auf einen WAP 
Oder WEB-Server (5) zugreifen kann, 
wobei das benannte Endgerat (1) eine Anfrage fur den 
benannten Server an ein WAP-Gateway (3) sendet, 

wobei die Sicherheit in der Luftschnittstelle (2) zwi- 
schen dem benannten WAP-tauglichen Endgerat 
(1) und dem benannten Gateway (2) auf WTLS 
(Wireless Transport Layer Security) basiert, 
wobei der benannte Server (5) mit dem SSL und/ 



Oder TLS Sicherheitsprotokoll gesichert ist, 
wobei die Konversion zwischen WTLS und SSL 
und/oder TLS in einem vom Verwalter des benann- 
ten Servers (5) verwalteten gesicherten Gebiet er- 
folgt, 

und wobei die Pakete, die vom benannten Endgerat 
(1) gesendet werden, vom benannten Gateway (3) 
zum benannten gesicherten Gebiet weitergeleitet 
werden, ohne dass alle Pakete die wahrend einer 
Session ubertragen werden entschlusselt werden. 
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Besehreibung 

[CX)01] Die vorliegende Erfindung betrifft ein Verfahren, mit welchem ein Mobilteilnehmer mit einem WAP-tauglichen 
Endgerat auf einen WAP oder WEB-Server zugreifen kann. 
s [0002] WAP (Wireless Application Protocol)-Server, welche WAP basierte Dienste zur Verfugung stellen, sind an 
sich schon bekannt. Insbesondere sind auf WAP-basierte Dienste im Bereich von e-commerce und von finanziellen 
Instituten erhaltlich. 

[0003] Solche Dienste verlangen eine gesicherte Paketubertragung zwischen den Endbenutzern und dem Server 
des Dienstanbieters. Die gewohnliche undvom WAP-Forum empfohlene Losung verwendet die WTLS-Protokollschicht 

10 (Wireless Transport Layer Security); dieses Verfahren kann jedoch nur zum sichern der Paketubertragung zwischen 
den Endgeraten und einem (beispielsweise vom Mobilfunknetzbetreiber verwalteten) Gateway verwendet werden. In 
diesem Gateway wird eine Protokollubersetzung zum Sicherheitsprotokoll SSL 3.1 oder zum TLS 1 .0 durchgefuhrt. 
[0004] Das Prinzip einer mit diesem Verfahren gesicherten Datenubertragung ist schematisch auf der Figur 2 dar- 
gestellt. Mit dem Bezugszeichen 1 ist ein WAP taugliches Endgerat, beispielsweise ein WAP -taugliches GSM-Mobil- 

is funktelefon (Global System for Mobile Communication) dargestellt, das sich uber ein digitales Mobilfunknetz 2 mit 
einem vom Betreiber dieses Netzes verwalteten Gateway verbinden kann. Das Endgerat 1 enthalt ein Browser Mit 5 
ist ein Server eines Dienstanbieters, beispielsweise eines Finanzinstituts oder eines Anbieters im e-commerce Bereich, 
dargestellt. Dieser Server kann auf eine Datenbank 51 zugreifen, in welcher WEB und/oder WAP-Seiten gespeichert 
sind. Die WEB Oder WAP-Seiten konnen beispielsweise HTML-, WML-, JAVA-Script-, WML-Script-, usw., Dokumente 

20 enthalten. 

[0005] Der Benutzer des Endgerats 1 , der auf eine WEB-oder WAP-Seite in der Datenbank 51 zugreifen kann, muss 
zu diesem Zweck eine mit WTLS-Diensten gesicherte Anfrage durch das Gateway 3 zum Server 5 senden. Diese 
Anfrage wird im Gateway 3 durch alle Protokollschichten eines Konvertierungsmoduls 30 entschlusselt, und dann in 
eine mit TLS oder SSL gesicherte Anfrage ubersetzt, die uber ein TCP/IP Netz 4 an den Server 5 gesendet wird. Im 
25 Server 5 kann ein anderes Ubersetzungsmodul vorgesehen werden, das diese Anfrage in ein eigenes Format konver- 
tiert, welches vom Datenbankverwaltungssystem 51 verstanden werden kann. Die Antwort vom Server 5, beispiels- 
weise der Inhalt einer WEB oder WAP-Seite, wird in der anderen Richtung uber das Gateway 3, wo es umkonvertiert 
wird, zum Endgerat 1 geleitet. 

[0006] Dieses Verfahren erlaubt keine echte End-zu-End Verschlusselung; Daten und Pakete mussen im Gateway 
30 3 entschlusselt und wieder verschlusselt werden, damit die Protokollubersetzung durchgefuhrt wird. Fur viete Anwen- 
dungen ist eine solche Sicherheitslucke jedoch nicht akzeptierbar 

[0007] Ein Ziel der voriiegenden Erfindung ist es, ein neues sichereres Datenubertragungsverfahren zwischen einem 
Endgerat und einem WAP oder WEB-Server anzubieten. 

[0008] Ein anderes Ziel ist es, ein neues Verfahren anzubieten, mit welchem eine End-zu-End gesicherte Verbindung 
35 zwischen einem WAP-tauglichen Endgerat und einem WAP oder WEB-Server hergestellt werden kann. 

[0009] Ein weiteres Ziel ist es, ein neues Verfahren anzubieten, welches mit jedem WAP-tauglichen Endgerat das 

WTLS verwendet, e in gesetzt werden kann, insbesondere mit Endgeraten, die eine Serverauthentifizierung basierend 

auf einem RSA-Schiussel, auf X.509v3 Zertifikaten, auf RC5 oder auf anderen Sicherheitsprotokollen gemass WAP 

oder WTLS, bzw. auf weiteren digitalen Zertifikaten, verwenden. 
40 [001 0] Gemass der voriiegenden Erfindung werden diese Ziele insbesondere durch die Merkmale der unabhangigen 

Anspruche erreicht. Weitere vorteilhafte Ausfuhrungsformen gehen ausserdem aus den abhangigen Anspruchen und 

der Besehreibung hervor. 

[0011] Insbesondere werden diese Ziele durch ein Verfahren erreicht, in welchem das benannte Endgerat eine An- 
frage fur den benannten Server an ein WAP-Gateway sendet, wobei die Sicherheit in der Lurtschnittstelle zwischen 

45 dem benannten WAP-tauglichen Endgerat und dem benannten Gateway auf WTLS (Wireless Transport Layer Security) 
basiert, wobei der benannte Server eine SSL und/oder TLS Protokollschicht enthalt, wobei die Konversion zwischen 
WTLS und SSL und/oder TLS in einem vom Verwalter des benannten Servers verwalteten gesicherten Gebiet erfolgt, 
und wobei die Pakete, die vom benannten Endgerat gesendet werden, vom benannten Gateway zum benannten ge- 
sicherten Gebiet weitergeleitet werden, ohne alle Pakete, die wan rend einer Session ubertragen werden, zu entschlus- 

so seln. 

[0012] Die Pakete werden durch eine sogenannten Tunnelschicht durch das Gateway ubertragen, ohne dass sie 
entschlusselt werden. Dadurch bleibt der Inhalt selbst dem Betreiber des Gateways unbekannt. Die Pakete werden 
dann erst beim Server des Dienstanbieters in einem Proxy (sogenannten E2ES-Proxy) entschlusselt und mit dem 
Zertifikat einer vertrauten Drittinstanz verifiziert. 
55 [0013] Ausserdem werden diese Ziele durch ein Verfahren erreicht, mit welchem ein Mobilteilnehmer mit einem 
WAP-tauglichen Endgerat auf einen WAP oder WEB-Server zugreifen kann, wobei das benannte Endgerat eine An- 
frage fur den benannten Server an ein WAP-Gateway sendet in welchem ein Browser im benannten Endgerat die 
Portnummer der beantragten WEB oder WAP-Seite extrahiert und in die zum benannten Gateway gesendeten Pakete 
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kopiert, und in welchem die benannten Pakete im benannten Gateway in Abhangigkeit von dieser Portnummer wei- 
tergeleitet werden. 

[001 4] Ausserdem werden diese Ziele dadurch errecht, dass die Anfrage, die von einem Endgerat uber ein Gateway 
an einen WEB oder WAP-Server gesendet wird. mit WTLS End-zu-End gesichert wird. 
5 [0015] Vorzugsweise kann im Gateway zwischen Sessionen, die konventionell behandelt werden sollen und Ses- 
sionen, die gemass der vorliegenden Erfindung weitergeleitet werden sollen, unterschieden werden. 
[0016] Im Folgenden werden anhand der beigefugten Zeichnung bevorzugte Ausfuhrungsbeispiele der Erfindung 
naher beschrieben: 

[0017] Die Figur 1 vergleicht die Protokollschichten in einem WAP-Protokoll-Stapel und im Internet Protokoll-Stapel. 
10 [001 8] Die oben beschriebene Figur 2 zeigt das Prinzip einer gesicherten Datenubertragung gemass dem normaten 
WAP-Protokoll. 

[001 9] Die Figur 3 zeigt das Prinzip einer gesicherten Datenubertragung gemass einer ersten variante der Erfindung. 
[0020] Die Figur 4 zeigt das Prinzip einer gesicherten Datenubertragung gemass einer zweiten Variante der Erfin- 
dung. 

is [0021] Die Figur 5 zeigt das Prinzip einer gesicherten Datenubertragung gemass einer dritten Variante der Erfindung. 
[0022] Die Figur 3 zeigt das Prinzip einer ersten variante der Erfindung. Diese Figur zeigt ein in einem digitalen 
Mobilf unknetz 2 angemeldetes WAP-taugliches Endgerat 1 , beispielsweise ein WAP-taugliches GSM-Mobiifunktelefon 
Oder einen WAP-tauglichen tragbaren Rechner. Mit diesem Gerat kann ein Programm, beispielsweise ein WAP-Brow- 
ser, ausgefuhrt werden, das sich als Kunde mit einem WAP und/ Oder WEB-Server 5 verbinden kann und somit auf 

20 Daten in diesem Server zugreifen kann. 

[0023] Der WAP- oder WEB-Server 5 enthalt WML und/oder HTML-Seiten, die beispielsweise von einem Dienstan- 
bieter (beispielsweise einem Finanzinstitut und/oder einem Anbieter im Bereich e-commerce) angeboten werden. Es 
wird oft von Dienstanbietern und Endbenutzern gewunscht, dass die Session die aufgebaut wird wenn ein Benutzer 
auf mehrere Seiten zugreift, gesichert wird. Insbesondere ist es oft notig, dass manche Daten, die in beiden Richtungen 

25 zwischen dem Endgerat 1 und dem Server 5 ubertragen werden, End-zu-End gesichert werden und dass keine Dritt- 
4 partei, nicht einmal der Mobilf unknetzbetreiber, diese Daten entschlusseln kann. Ausserdem wird eine gegenseitige 

* Authentisierung des Dienstanbieters und des Mobilbenutzers benotigt. 

[0024] Der Benutzer des Endgerats kann eine gesicherte Seite erreichen : beispielsweise um eine Transaktion durch- 
zuf uhren, indem er beispielsweise auf den entsprechenden URL einer gesicherten oder nicht gesicherten Seite klickt. 

30 Der vom Dienstanbieter definierte URL der Seite kann beispielsweise http://www.sp1. com: 50443 lauten, wobei http:// 
www.sp1.com die URL-Adresse des Dienstanbieter und 50443 seine Portnummer ist. In Wap werden hingegen die 
•« fortlaufenden Portnummerbereiche 920x angewendet. * 

[0025] Erfindungsgemass werden die URL in den WML und/oder HTML-Seiten der Dienstanbieter so verfasst, dass 
die gewunschte Sessionsart (End-zu-End gesichert, Standard gesichert oder ungesichert) aus diesem URL, unter 

35 anderem aus der URL-Adresse und/oder aus der Portnummer, ermittert werden kann. 

[0026] Mit dem Bezugszeichen 3 ist ein ebenfalls dem Mobilf unknetz 2 angeschlossenes Gateway dargestellt. Das 
Gateway nimmt die Pakete vom Benutzer 1 entgegen und entschlusselt das oder die ersten Pakete in jeder Session, 
bis eine Anwendung 314 die Portnummer und die URL der gewunschten WEB oder WAP-Seite aus den Paketen 
extrahieren kann. 

40 [0027] Sobald diese Angaben gef unden worden sind, bestimmt die Anwendung 31 4 anhand den vom Verwalter des 
Gateways angegebenen Angaben, wie die Pakete bearbeitet werden sollen. Insbesondere bestimmt die Anwendung, 
ob die Session zwischen dem Endgerat 1 und dem Server 5 End-zu-End gesichert werden soil. Dies ist beispielsweise 
dann der Fall wenn sich die Portnummer (beispielsweise 50443) in einer vom Administrator des Gateways auf gebauten 
Liste befindet. 

45 [0028] Das Gateway 3 verwendet eine zusatzliche Protokollschicht 310 (Tunnelschicht), die von der Anwendung 
31 4 gesteuert wird (Pfei! 315). Wenn die Session gesichert werden soil, wird die Tunnelschicht 31 0 so gesteuert, dass 
alle nachfolgenden Pakete der Session in transparenter Art durch das Gateway gefuhrt und an die Zieladresse des 
Servers 5 weitergeleitet werden, ohne konvertiert und vor allem ohne entschlusselt zu werden. 

[0029] Die immer noch mit WTLS gesicherten Pakete der Session werden dann uber das Netz 4 weitergeleitet und 
50 vom Server 5 im gesicherten Gebiet des Dienstanbieters entgegengenommen. Das Netz 4 kann beispielsweise aus 
dem Internet oder aus einer gemieteten Telefon-Linie bestehen. Der Server 5 umfasst ein Proxy 52 welches spater 
erlautert wird, ein konventionelles Gateway 50, und eine Datenbank 51, in welcher ein WEB- und/ oder WAP-lnhalt 
abgelegt ist. 

[0030] Das Proxy 52 im Server 5 des Dienstanbieters wird so aufgebaut, dass es WTLS -gesicherte Sessionen ent- 
55 gegennehmen kann. Es umfasst vorzugsweise einen kompletten WAP-Protokoll-Stapel und kann somit durch vom 
Fachmann leicht durchfuhrbare Anpassungen von standardisierter Software realisiert werden. In diesem Proxy werden 
empfangene mit WTLS gesicherte WDP-Datagramme mit dem Zertifikat einer vertrauten Drittinstanz gepruft, ent- 
schlusselt und in normale TCP-IP-Datagramme ubersetzt, wobei die HTTP-Session optional mit SSL gesichert werden 
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kann. Die TCP-IP konvertierten Pakete werden an den WAP- oder WEB-Server 50 weitergeleitet, der eventuell eine 
andere Protokollkonvertierung durchf uhrt, damit die empfangene Abf rage vom Datenbanksystem 51 bearbeitet werden 
kann. 

[0031] Als Alternative konnen die Datagramrne rnit einem Session-Schlussel ver- und entschlusselt werden, dssen 
5 Schlussel mit Hilfe eines zertifizierten, dffentlichen Schlussel wahrend der Schlusselvereinbarungsphase generiert 
werden. 

[0032] Die Antwort vom WEB bzw. WAP-Server 50, zum Beisptel die gewunschte WEB- oder WAP-Seite, wird vom 
Server 50 in die andere Richtung gesendet, im Proxy 52 Obersetzt und mil WTLS-Diensten gesichert und durch die 
"Tunnelschicht" 310 im Gateway 31 an das Endgerat 1 des Benutzers geleitet, wobei die gesamte Verbindung zwischen 

10 Server 5 und Endbenutzer 1 mit WTLS gesichert wird. 

[0033] Datagramrne, die aufgrund des enthaltenen URL und/oder Portnummer keine End-zu-End gesicherte Daten- 
ubertragung verlangen, werden im Gateway 31 gemass der konventionellen vom WAP-Forum empfohlenen Losung 
durch alle Schichten des Protokolls im Gateway 2 entschlusselt, mit TLS/SSL wieder gesichert und an die in den 
Paketen angegebene URL-Adresse weitergeleitet. Beispielsweise werden Sessionen mit der Portnummer 80 wie ge- 

is wohnliche HTTP-Sessionen behandelt und weitergeleitet. 

[0034] Antworten vom Server 5 (beispielsweise die gewunschten WE B Oder WAP-Seiten) die keine WTLS-Sicherung 
zwischen Server und Gateway 3 verlangen, werden von der Proxy-Anwendung 524 durch eine Tunnelschicht 520 im 
Proxy durchgefuhrt (Pfeil 315) und erst im Gateway 3 mit WTLS-Diensten gesichert. 

[0035] Diese Variante verlangt keine Anderungen vom Browser im Endgerat 11 und nur ein relativ einfaches Proxy 
20 53 beim Dienstanbieter 5, das WTLS-Sessionen entgegennehmen kann. Die Software-Implementation des Gateways 
3 kann sich jedoch als schwierig erweisen. 

[0036] Die zweite Variante, die auf der Figur 4 dargestellt wird, erlaubt es, dieses Problem durch eine leicht durch- 
fuhrbare Anpassung der Anwendung (zum Beispiel des Browsers) im Endgerat 1 zu vermeiden. In dieser Variante wird 
die URL-Adresse und die Portnummer der verlangten WEB oder WAP-Seite vom Browser 10 in jedes Paket (WDP- 

2S Datagramm) der Session kopiert. Diese Pakete werden dann uber das Mobilfunknetz 2 an das Gateway 3 gesendet, 
wo die Portnummer und die URL analysiert werden, um zu ermitteln wie die Pakete weiterbehandelt werden sollen. 
[0037] Diese Variante hat den Vorteil, dass die Analyse und die Weiterbehandlung der Pakete in den unteren Schich- 
ten des Protokolls, unter anderem in der WDP und/oder WTLS-Schicht, durchgefuhrt werden kann und dass sie somit 
nur minimale Anpassungen des Gateways 3 verlangt. 

30 [0038] Eine Tabelle 321 im Gateway 3 oder in einem nicht dargestellten Router vor dem Gateway gibt an, wie die 
Pakete je nach Portnummer und URL behandelt werden sollen und insbesondere welche Pakete transparent durch 
die Tunnelschicht 320 gehen sollen. Diese Tabelle kann vorzugsweise vom Administrator des Gateways 3 konfiguriert 
und geandert werden, ohne dass das Gateway neu gestartet werden muss, damit die Konfiguration wahrend des 
Betriebes aktualisiert werden kann. Daten in der Tabelle konnen vorzugsweise nur vom Administrator geandert werden, 

35 oder von Personen mit Administratorenrechten. 

[0039] Die Tabelle im Gateway 3 konnte beispielsweise folgende Zeilen enthalten: 







Eingegebene URL Adresse 


Neue Adresse (vom Gateway erteilt) 


Bemerkung 


40 




Adresse 


Portnummer 


Adresse 


Portnummer 




45 


1 


138.10.20.30 


8040 


140.50.60.70 


12345 


Pakete mit dieser Adresse werden 
auf transparente Weise an die 
neue Adresse geleitet. Die 
Portnummer wird ersetzt 
(Mapping). 




2 


* * * * 


50443 


* * * * 


50443 


Stern-Joker erlauben eine 
Bedingung fur alle Server mit der 
gleichen Portnummer zu setzen 


SO 


3 


138.10.20.40 


* 


138.10.20.40 


* 


Wie oben, jedoch ohne DNS- 
Lookup 




4 


www.sp1.com 


* 


www.sp1.com 


* 


Alle URL vom sp1 mussen durch 
die Tunnelschicht 


55 


5 


www.sp1.com 


80 


www.sp1.com 


80 


Alle Verbindungen mit 
Portnummer 80 durch die 
Tunnelschicht 
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(fortgesetzt) 





Eingegebene URL Adresse 


Neue Adresse (vom Gateway erteilt) 


Bemerkung 


Adresse 


Portnummer 


Adresse 


Portnummer 


6 


\ am aaa/ cr\1 
WWW. bp I . L>I 1 




www sd1 ch 


50443 


sp1 verlangt, dassalle Sessionen 
mit der Portnummer 50443 durch 
dieTunnelschicht geleitet werden. 


7 


www.sp2.ch 


443 


www.sp2.ch 


443 


enO warlannt Hacc alio Qpcctnnpn 
bp^ Vciraiiyi, udoo due ocooiui ici i 

mit der Portnummer 443 durch die 
Tunnelschicht geleitet werden. 
Damit wird kein SSL mit dem Port 
443 verwendet. SSL kann dann 
beispielsweise vom Proxy 
verwendet werden. 


8 













[0040] Der Administrator des Gateways 3 wird vorzugsweise den Dienstanbietern einen Bereich von URL-Adressen 
20 und/oder Portnummern zur Verfugung stellen. Dienstanbieter SP1, SP2 : usw. konnen dann eine oder mehrere URL, 
Oder Portnummern, oder Kombinationen aus beiden, fur sich reservieren und den Administrator 3 anweisen, Pakete 
mit dieser URL und/oder Portnummer transparent weiterzuleiten. 

[0041] Die Figur 5 zeigt als Beispiel, wie die Pakete, die von verschiedenen Endbenutzem 1 1 bis 1 4 gesendet werden, 
vom Gateway 3 in Abhangigkeit ihrer URL-Adresse und/oder Portnummer behandelt werden. 
25 [0042] Das dargestelfte System umfasst in diesem Beispiel drei Server 5, , 5 2 und 5 3 von drei verschiedenen Dienst- 
anbietern sp1 , sp2 und sp3. Die vier folgenden Seiten werden im ersten Server 5^ (bzw. 5 2 ) abgelegt: 

■ eine ungesicherte WEB-Seite mit der Adresse www.spl .com:80 (bzw. www.sp2.com:80) i 

30 ■ eine WEB-Seite mit der Adresse www.spl com:443 (bzw. www.sp2.com:443), die nurmit SSL gesichert wird (keine 
End-zu-End Sicherheit) 

■ eine WEB-Seite mit der Adresse www.spl .com:50443 (bzw. www.sp2.com :50443), die mit WTLS gesichert wird 
(End-zu-End Sicherheit) 

35 — 

■ eine WAP-Seite mit der Adresse wap.spl .com: 50443 (bzw. wap.sp2.com: 50443), die mit WTLS gesichert wird 
(End-zu-End Sicherheit) 

[0043] Im Server 5 3 des dritten Dienstanbieters sp3 werden nur zwei Seiten abgelegt: 

40 

■ eine ungesicherte WEB-Seite mit der Adresse www. sp3.com: 80 

■ eine WEB-Seite mit der Adresse www. sp3.com: 443, die nur mit SSL gesichert wird (keine End-zu-End Sicherheit) 

45 [0044] Der erste Benutzer 1 -, will auf die gesicherten Seiten www.spl .com:443 und www.spl .com:50443 des Dienst- 
anbieters SP1 im Server 5, zugreifen, indem er GET(URL) Abfragen mit entsprechenden URL an das Gateway 3 
sendet. Das Gateway 3 erkennt anhand der Tabelle 321 und des im Datagramm enthaltenen URL und/oder der Port- 
nummer, welche Sicherheiten von diesen Seiten verlangt werden. Im ersten Fall (SSL Sicherheit) werden alle Data- 
gramme der Session im Gateway 3 entschlusselt und eine Ubersetzung von WTLS zu SSL wird durchgefuhrt. Im 

so zweiten Fall (End-zu-End Sicherheit mit WTLS) werden alle Datagramme der Session transparent an den Server 5 1 
weitergeleitet, ohne dass sie entschlusselt werden. 

[0045] Der zweite Benutzer 1 2 will aut die Seite www.sp2.com:50433 des Dienstanbieters sp2 im Server 5 2 zugreifen, 
die eine End-zu-End Sicherheit verlangt. Datagramme mit dieser Adresse werden im Gateway 3 erkannt und transpa- 
rent durch die Tunnelschicht an den Server 5 2 geleitet. 
55 [0046] Der dritte Benutzer 13 will auf die Seite www.sp3.com:443 des Dienstanbieters sp2 im Server 5 2 zugreifen, 
die eine mit TLS/SSL gewahrleistete Sicherheit verlangt. WTLS-gesicherte Datagramme mit dieser Adresse werden 
im Gateway 3 erkannt, durch alle Schichten des Protokoll-Stapels ubersetzt, mit TLS/SSL gesichert und an den Server 
5 2 weitergeleitet. 
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[0047] Der vierte Benutzer 1 4 will auf die ungesicherte Seite www. sp3.com: 80 des Dienstanbieters sp2 im Server 

5 2 zugreifen. WTLS-gesicherte Pakete mit dieser Adresse werden im Gateway 3 erkannt durch alle Schichten des 

Protokoll-Stapels Obersetzt und an den Server 5 3 weitergeleitel, ohne sie durch das Netz 4 zu sichern. 

[0048] Diese Variante verlangt nur minimale Anderungen vom Gateway 3. Allerdings mussen die Browse r-An we n- 

dungen in den Endgeraten 1 leicht angepasst werden, was sich bei vielen Anbietern als schwierig erweisen kann. 

[0049] Wir werden jetzt eine dritte Erfindungsvariante beschreiben, die diesen Nachteil vermeidet. 

[0050] In dieser Variante werden Sessionen die eine End-zu-End Sicherheit verlangen anhand der URL-Adresse 

und/oder der Portnummer wie in der ersten oder zweiten Variante erkannt. Statt die Sessionen durch die Tunnelschicht 

transparent weiterzuleiten, sendet das Gateway in diesem Fall einen standardisierten Redirect-Befehl mit der in der 

Tabelle 321 angegebenen Adresse und Portnummer des Dienstanbieters und mit anderen Parameter fur die Identifi- 

zierung vom Gateway 5, wie Dial-In Nummer, an das Endgerat 1 . 

[0051] Die Weiterleitungsadresse (Adresse, Portnummer, Dial-In Nummer, usw.) im Redirect-Befehl wird vorzugs- 
weise aus einem vom WAP oder WEB-Server 5 zuganglich gemachten Dokument extrahiert Der Redirect-Befehl kann 
auch dieses oder ein anderes Dokument oder die Adresse eines solchen Dokuments enthalten, in welchem die Wei- 
terleitungsadresse enthalten ist. Im Dokument konnen vorzugsweise verschiedene Adressengebiete mit Stringmuster, 
beispielsweise mit *, angegeben werden. 

[0052] Die Anwendung im Mobilgerat "I, die diesen Redirect Befehl entgegennimmt. reagiert, indem sie jetzt die 
schon vorher an das Gateway 3 gesendeten Pakete wieder direkt an die im Redirect-Befehl angegebene Adresse des 
Dienstanbieters sendet. 

[0053] Alle Pakete in der Session werden dann direkt zwischen dem Endgerat 1 und dem Server 5 ubertragen, bis 
der Endbenutzer einen anderen URL sendet, der vom Server 5 nicht bearbeitet werden kann (beispielsweise wenn 
sich die entsprechende gewunschte Seite nicht auf diesem Server befindet). In diesem Fall wird die Session vom 
Server 5 unterbrochen und die nachfolgenden Pakete werden wieder an das Gateway 3 gesendet. 
[0054] Falls keine End-zu-End Sicherheit benotigt wird : wird kein Redirect Befehl vom Gateway 3 gesendet. In die- 
sem Fall werden alle Pakete wahrend der gesicherten Session durch das Gateway 3 gesendet. 



Patentanspruche 

1. Verfahren, mit welchem ein Mobilteilnehmer mit einem WAP-tauglichen Endgerat (1) auf einen WAP oder WEB- 
Server (5) zugreifen kann, 

wobei das benannte Endgerat (1) eine Anf rage fur den benannten Server an ein WAP-Gateway (3) sendet, 

wobei die Sicherheit in der Luftschnittstelle (2) zwischen dem benannten WAP-tauglichen Endgerat (1) und 

dem benannten Gateway (3) auf WTLS (Wireless Transport Layer Security) basiert, 

wobei der benannte Server (5) mit dem SSL und/oder TLS Sicherheitsprotokoll gesichert ist, 

dadurch gekennzeichnet, dass die Konversion zwischen WTLS und SSL und/oder TLS in einem vom Ver- 
walterdes benannten Servers (5) verwalteten gesicherten Gebiet erfolgt, 

und dass die Pakete, die vom benannten Endgerat (1) gesendet werden, vom benannten Gateway (3) zum 
benannten gesicherten Gebiet weitergeleitet werden, ohne alle Pakete die wahrend einer Session ubertragen 
werden zu entschlusseln. 

2. Verfahren gemass Anspruch 1 , dadurch gekennzeichnet, dass das benannte Gateway (3) die benannten Pakete 
zu einem Proxy (52) im benannten gesicherten Gebiet weiterleitet, wobei das benannte Proxy (52) mindestens 
eine Protokollschicht des WAP-Protokolls verwendet. 

3. Verfahren gemass einem der Anspruche 1 oder 2, in welchem die benannten Pakete in Abhangigkeit vom URI 
und/oder vom Domainname der angef ragte Seite im benannten Gateway (3) weitergeleitet werden. 

4. Verlahren gemass einem der vorhergehenden Anspruche, in welchem die benannten Pakete abhangig von der 
Portnummer im benannten Gateway (3) weitergeleitet werden. 

5. Verfahren gemass dem vorhergehenden Anspruch, in welchem die benannten Pakete abhangig von verschiede- 
nen Portnummern an verschiedene gesicherte Gebiete weitergeleitet werden. 

6. Verfahren gemass einem der Anspruche 4 oder 5, in welchem die benannte Portnummer aus der URI und/oder 
URL der angefragten Seite in einer Anwendungsschicht des benannten Gateways (3) extrahiert werden. 
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7. Verfahren gemass Anspruch 6, in welchem die benannte Portnummer wahrend einer Session nur aus einer be- 
grenzten Anzahl von Paketen extrahiert wird, 

und in welchem das Weiterleiten von mindestens einem folgenden Paket von dieserbenannten extrahierten 
Portnummer abhangig ist. 

8. Verfahren gemass Anspruch 7, in welchem ein Proxyserver (52) im benannten gesicherten Gebiet die URI und/ 
oder die Portnummer der emptangenen Pakete extrahiert, und in welchem der benannte Proxyserver (52) dem 
benannten Gateway (3) einen Befehl zurucksendet, wenn er ein Paket mit einer anderen URI und/oder mit einer 
anderen Portnummer empfangt. 

9. Verfahren gemass einem der Anspruche 4 oder 5, in welchem die benannte Portnummer aus dem benannten URI 
und/oder URL der angefragten Webseite im benannten Endgerat (1) extrahiert wird. 

10. Verfahren gemass Anspruch 9, in welchem die benannte Portnummer von einem Browser aus dem URI und/oder 
URL der angefragten Webseite extrahiert wird. 

11. Verfahren gemass einem der Anspruche 8 oder 9, in welchem der Browser im benannten Endgerat (1 ) die benannte 
Portnummer in den benannten Paketen erst dann kopiert, wenn eine End-zu-End gesicherte Verbindung beantragt 
ist. 

12. Verfahren gemass einem der Anspruche 3 bis 11, in welchem die benannten Pakete im benannten Gateway (3) 
an ein gesichertes Gebiet weitergeleitet werden wenn sich die benannte Portnummer in einem vorbestimmten 
Bereich befindet. 

.13. Verfahren gemass Anspruch 1 , dadurch gekennzeichnet, dass wenn eine End-zu-End gesicherte Verbindung be- 
antragt ist, das benannte Gateway (3) einen Redirect-Befehl zum benannten Endgerat (1) sendet. 

14. Verfahren gemass dem vorhergehenden Anspruch, in welchem der benannte Redirect Befehl zeitlich begrenzt ist. 

.15; ; Verfahren gemass Anspruch 13, in welchem ein Proxy Server (52) im benannten gesicherten Gebiet die URI und/ 
oder die Portnummer der empfangenen Pakete extrahiert, und einen Redirect Befehl zuruck zum benannten End- 
gerat (1) sendet, sobald die Session zum benannten Gateway (3) weitergeleitet werden soli. 

16. Verfahren gemass Anspruch 13, in welchem den benannten Redirect-Befehl eine Weiterleitungsadresse enthalt, 
die aus einem vom benannten WAP oder WEB-Server (5) zuganglich gemachten Dokument extrahiert wird. 

17. Verfahren gemass dem Anspruch 13 : in welchem den benannten Redirect-Befehl ein Dokument enthalt, in wel- 
chem die Weiterleitungsadresse enthalten ist. 

18. Verfahren, mit welchem ein Mobilteilnehmer mit einem WAP-tauglichen Endgerat (1) auf einen WAP oder WEB- 
Server (5) zugreifen kann, 

wobei das benannte Endgerat (1) eine Anfrage fur den benannten Server (5) an ein WAP-Gateway (3) sendet, 

dadurch gekennzeichnet, dass ein Browser im benannten Endgerat (1) die Portnummer der beantragten WEB 

oder WAP-Seite extrahiert und in zum benannten Gateway (3) gesendete Paketen kopiert, 

und dass die benannten Pakete im benannten Gateway (3) in Abhangigkeit von dieser Portnummer weitergeleitet 

werden. 

19. Gateway (3), das mit WTLS-gesicherte Datagramme von WAP-tauglichen Endgeraten entgegennehmen und in 
SSL-gesicherte-Abfragen ubersetzen kann, 

dadurch gekennzeichnet, dass es Datagramme erkennen kann, die in transparenter Weise weitergeleitet 
werden sollen und dass es diese Datagramme ohne sie zu entschlusseln weiterleiten kann. 

20. Gateway gemass dem vorhergehenden Anspruch, in welchem die benannten Pakete in Abhangigkeit vom URI 
und/oder vom Domainname der angefragten Seite weitergeleitet werden. 

21. Gateway gemass einem der Anspruche 19 oder 20, in welchem die benannten Pakete in Abhangigkeit von der 
Portnummer im benannten Gateway (3) weitergeleitet werden. 
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Gateway gemass dem vorhergehenden Anspruch, in welchem die benannten Pakete abhangig von verschiedenen 
Portnummern an verschiedene gesicherte Gebiete weitergeleitet werden. 

Gateway gemass einem der Anspruche 21 Oder 22, in welchem die benannte Portnummer aus dem URI und/oder 
URL der angef ragten Seite in einer Anwendungsschicht des benannten Gateways (3) extrahiert werden. 

Gateway gemass Anspruch 21 , in welchem die benannte Portnummer wahrend einer Session nur aus einer be- 
grenzten Anzahl von Paketen extrahiert werden, 

und in welchem das Weiterleiten von mindestens einem tolgenden Paket von dieser benannten extrahierten 
Portnummer abhangig ist. 
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